Add Bitwarden extension

This PR adds a new bitwarden extension under extensions/bitwarden/. It exposes a Vicinae UI on top of the third-party rbw Bitwarden CLI, supporting both upstream Bitwarden and self-hosted Vaultwarden deployments.

Motivation — why a native extension instead of Raycast compat

The official Raycast Bitwarden extension is not usable on Linux Vicinae for two structural reasons, neither fixable in a compat shim:

1. No Linux platform support. Its manifest declares "platforms": ["macOS", "Windows"] and its API layer downloads the official bw CLI binary scoped to macOS or Windows targets (see src/api/bitwarden.ts, cliInfo.downloadUrl). There is no Linux download path. Running the Windows binary under Wine is the typical workaround and is fragile; the macOS binary will not run on Linux at all.
2. No persistent process model in Vicinae. Raycast's extension keeps the bw session alive in-process across commands. Vicinae commands are short-lived (view / no-view / menu-bar) — each invocation spawns a fresh process and shares no in-memory state, so the official bw CLI's session token would either be re-issued (and re-prompted) on every command or would have to be persisted to disk by the extension itself. rbw solves this externally via its own rbw-agent (ssh-agent style), which is the right boundary for a credential-bearing daemon: it lives outside the extension, the user controls its lifetime, and the extension never holds the master password.

The result is a Linux-native Vicinae extension that does not download any binary, does not store the master password, and reuses an existing well-known agent (rbw-agent) for session persistence.

What it does

Eight commands:

Categories: Productivity, Security.

Requirements

The extension shells out to rbw for all vault operations. It does not download any binary. If rbw is missing or not on the user's PATH (or at the configured cliPath), commands surface a clear BwNotFound error instructing the user to install rbw themselves.

Self-hosted Bitwarden / Vaultwarden is supported via the serverUrl preference. Self-signed CA bundles can be provided via serverCertsPath and are injected as SSL_CERT_FILE for the rbw child process.

Validation

Run inside extensions/bitwarden/:

• npx vici lint — manifest valid.
• npx vici build — built successfully (8 entrypoints).
• npm run lint — clean (eslint v9, flat config).
• npm test — 72 tests pass across 11 files (rbw adapter, vault, crypto cache, totp, prefs, mutex, errors).
• npm install — package-lock.json generated, 0 vulnerabilities.

How to test

1. Install rbw on the system.
2. In Vicinae preferences, set clientId and clientSecret (Bitwarden API key from Settings → Security → Keys). For self-hosted, also set serverUrl.
3. Run Search Vault — first launch will prompt for the master password; subsequent launches use the cached rbw session.
4. Try Authenticator on an item with a TOTP URI — codes refresh on the shared interval.
5. Try Generate Password + Generate Password (Quick) — the quick variant copies and exits without rendering a view.
6. Sync Vault, Lock Vault, and Log Out are no-view commands surfacing toast feedback.

Sensitive fields (passwords, secure notes, card data, identity fields) are never written to disk. The optional encrypted local cache (shouldCacheVaultItems) only holds non-sensitive metadata (names, URIs, folder ids) for fast list rendering and is keyed by the master password.

Compliance with GUIDELINES.md

• Directory extensions/bitwarden/ matches manifest name.
• package-lock.json generated with npm install (per "we only support npm" note in .gitignore).
• bun.lock not included.
• Uses @vicinae/api. Does not use @raycast/api.
• Icon: assets/icon.png, 2048×2048, 1:1.
• All commands have description. Extension description is concise.
• No binaries downloaded. External dependency (rbw) is a well-known, user-installed CLI.

AI Disclosure

This extension was developed with the assistance of Claude Code (Anthropic). The TypeScript source, manifest, README, tests, and this PR description were drafted with AI assistance and reviewed line-by-line by the contributor before submission. The choice of architecture (rbw subprocess wrapper, encrypted non-sensitive metadata cache, master-password reprompt grace window, shared TOTP clock) was made by the contributor; AI was used to implement and refactor against that design. The contributor reviewed all output before submission. Review responses may continue to use AI assistance; all responses will be reviewed and verified by the contributor before posting.